參數的命名規則。
基本上Parameters或Arguments的命名規則會跟者變數的命名規則走：用camelCase，在名稱上要突顯他的特徵，如果是array或collection記得改成複數型...等等。

private void MoveToArchieve(int accountId, string assignedStorage);

所以今天的分享結束(咦?)

下面才是正題 :D
也許只有我，但如果熟悉SOLID原則的人應該都會覺得，參數是個很麻煩的東西。
不知道有沒有聽過"參數不能超過七個"這種說法？意思就是一個方法的參數最好不要超過七個，這個規則連微軟都有偷偷置入這個規則喔。

也許是腦補，但這個原則其實很多地方都看得到。

其實不難理解為什麼會有這種說法：人的腦袋可以接受或記憶的數量很有限，就算在有工具輔助的情況之下，也很難處理超過一定數量的資訊。

function createAccount(userid, username, aliasName, address1, address2, address3, phoneNumber, otherArgmentWeDoNotCareAbout) {
...
}

這種寫法真的會造成疲乏，所以太多的參數也會被視作一種Code smell，應該要被避免。
理想上的方法應該不帶任何參數的，但如果一定要帶參數的話，也應該盡可能的減少參數的數量，例如上面的例子，應該重構成

function createAccount(userInfo, address, otherArgmentWeDoNotCareAbout) {
...
}

為什麼會提到SOLID原則呢？這個原則裡有一項叫"Open-closed principle，開放/關閉原則，意思是一個物件要對擴展功能開放，而對修改功能關閉。
什麼意思呢，就是如果一個方法己經寫好了，如果要修改它的行為，應該要在不修改原始碼的情況下修改。
其實也不難理解這背後的原因啦，特別是public method，如果每個需求都可以隨意的更動他的邏輯，那這個方法就會隨時處於不穩定的情況。
方法本身的處理方法這裡暫時不提，但如果是參數面的話，我個人的處理方法是：只要有參數，一律寫成類別，無論數量多寡都透過類別來處理。雖然不是個很特別的東西，但運用上可以解決不少這類的問題。其實最適合的方法應該是包成JSON物件，然後在方法裡解析所有的參數出來，然後再往下走。

有人有看過爆長的參數列表嗎?我看過20+個參數的，真的只能用傻眼來形容，有人有更好的解法法？分享一下吧！